1. Field of the Invention
The present invention relates generally to information handling systems in which data is communicated between a processor and remote peripheral devices through a channel to peripheral controller over a serial data exchange link. More particularly the present invention relates to such information handling systems where the length of the serial link is increased by using channel extenders and where data chaining may be performed using a data streaming mode of data transfer.
2. Background of the Invention
There are many information handling systems known which transmit data between a processor channel and a peripheral device across a serial data transmission link. Channel extenders are often used in these systems to increase the distance that the processor and peripheral devices may be separated. One such system is described in U.S. Pat. No. 4,712,176, hereby incorporated by reference, assigned to the assignee as the present invention.
According to the referenced patent, data transfers across the serial link are controlled by control lines called "tags", in particular the tags Service In, Service Out, Data In and Data Out as described in the reference. These tags, collectively called data transfer tags, are raised and lowered in one of several predetermined sequences that control the progress of a data transfer. The actual data being transferred is carried on buses referred to as Bus In (for data being transferred toward the processor) and Bus Out (for data being transferred to the peripheral device) in the referenced patent.
Data transfer, on one interface described in the referenced patent, takes place at different rates that are appropriate to different devices, and in the simplest case the rate is controlled by the two data transfer tags Service Out and Service In. These signals are interlocked by the requirement that the signals are changed only in the following sequence: the control unit raises Service In, the channel raises Service Out, the Control Unit drops Service In, and the Channel drops Service Out. The procedure is commonly called handshaking. The interlocked mode is also called direct current interlocked mode.
Another data transfer mode described in the U.S. Pat. No. 4,712,176 is data streaming. In this mode a channel or a control unit raises a data transfer tag for a predetermined period of time and then drops the tag without waiting for a response by the receiving component. The receiving station sends the data transfer tags as in interlocked mode except that the tags are sent on the rise of the corresponding tag without waiting for the fall of the corresponding tag. The tags are counted to check that the number of tags sent equals the number of tags received.
In a conventional I/O channel which transfers data to and from control units using the aforementioned data streaming mode, there are minimum channel command word (CCW) byte count limitations particularly when performing "data chaining" operations.
Data chaining provides the ability to transfer multiple blocks of data within a single CCW. The first CCW of the data chain string has the control unit command (e.g., read or write), data address and a byte count. The rest of the CCWs in the chain do not have a command but do have a data address and byte count. This feature allows data transfer by a single control unit command to be scattered to multiple locations in main store during read operations or be gathered from multiple locations in main store during write operations. Since the control unit receives only one command for the entire string of data chained CCWs, it has no knowledge that data chaining is taking place. In the case of a read operation, the data chaining is interlocked in that data received from one CCW must be stored in main store before the next CCW in the string can be fetched from main store. Since both data and CCWs reside in the same memory (main store) interlocking allows data received by one CCW to alter the next data chain CCW. This interlocking reduces data transfer throughput.
Since it requires a relatively long time from the store of the last byte of data for one CCW to the fetch of the next CCW, the channel requires a method of throttling data transfer from the control unit during this period. The ability of the channel to throttle data transfer ensures that the channel has the new CCW byte count necessary to determine how to respond to the control unit. When the CCW byte count is not zero, the channel responds to the control unit with Service Out or Data Out; and when the byte count of the last CCW of the string reaches zero, the channel can respond to control unit requests with a Stop command (as described in the referenced patent by raising Command Out) and inform the control unit of how many bytes were transferred by the channel.
There are situations during data chained read operations when the channel will respond to requests from the control unit while it is fetching the next CCW. In this case the channel may accept more bytes than the sum of all of the CCW byte counts in the string. When the channel detects this condition, a "chaining check" indicator is set in a status word indicating that the read operation was unsuccessful.
Using a DC Interlocked type data transfer, there are two mechanisms for throttling data transfer, both of which are able to stop data transfer within one byte. Therefore, in DC Interlock mode the smallest data chained CCW byte count can be one.
The first throttling mechanism allows the channel to simply stop responding to control unit request (Service In and Data In) while the channel is storing data for the current CCW and fetching the next CCW. Since the control unit is in DC Interlock mode, it will not present another request to the channel until a response is received for the present request. Count control is always maintained. Byte multiplexer channels typically use this mechanism.
The second mechanism is Suppress Data Control, via a mechanism like the Suppress Out tag described in the referenced patent. During data transfer the channel can raise a Suppress Out interface line as it responds to the last byte for a CCW. The control unit must stop data transfer within one byte. In this case the channel may respond to this request, and the control unit will not make any more requests until the Suppress Out line drops. Since the smallest allowed data chained CCW count is one, the channel still has count control even though it has accepted one extra byte from the control unit. Selector and Block multiplexer channels typically use this mechanism.
These two mechanism allow channel programs to be written with Read data chaining CCW byte counts of one (1). With buffered control units these programs never cause data overruns or chaining checks.
However, in data streaming mode, the control unit is not required to wait for a response from the channel before generating more requests. This mode is not interlocked; therefore, there may be multiple requests (Service In and Data In tags) and multiple responses (Service Out, Data Out, and Command Out tags) on the I/O interface cable (including optical fiber) at the same time. The number of requests and responses on the interface is called "bytes in flight", and it is determined by the data rate and the apparent length of the interface and optical cable measured in time. This number becomes very large when a channel extender is part of the interface cable. For example, with a commercially available IBM 3044 channel extender connecting a control unit operating at 1 megabyte per second at a length of 2 kilometers, the number of "bytes in flight" is about 24. With an improved channel extender operating at 4.5 megabytes per second at the same length, this number increases to about 95.
Data chaining minimum byte count limitations are directly related to the number of "bytes in flight". Neither of the throttling mechanisms described for the DC Interlock mode are able to maintain channel count control. The first mechanism where the channel stops responding to request always causes data overruns in data streaming mode. In a conventional channel, responses are always immediately answered. The only time that a channel is unable to answer a request is when a channel buffer full or empty condition exists. If a conventional channel receives a request when this condition exists, it stops responding to any more requests from the control unit. The control unit detects that the channel has stopped, raises Status In and eventually signals an overrun. This drastic action is necessary to prevent the loss of the "bytes in flight" thereby ensuring data integrity. The second mechanism (Suppress Data Control) can be used in data streaming mode however, Suppress Out cannot stop data transfer within one byte because of the "bytes in flight". The channel has no knowledge of the number of "bytes in flight" and it must receive all of the data for a CCW before it can fetch the next CCW. Once Suppress Out is raised, all of the "bytes in flight" must be acknowledged by the channel. While these bytes are being acknowledged, the channel does not have count control since it is busy fetching the next CCW. When the channel finally receives the CCW, a chaining check will result if the channel received more bytes than it has buffering space to accommodate or if the sum of all the CCW byte counts in the string is less than the number of bytes accepted by the channel. In either of these cases, the channel program does not work in Data Streaming mode even though the CCW byte counts may be relatively large.
It would be desirable to have an information handling system capable of performing data chaining in a data streaming mode through a channel extender where, for example, the distance between a processor channel and perpherial device controller could be several (e.g. 1, 2 or 3) kilometers versus the less than 0.5 kilometer separation limitation imposed by state of the art systems.
It would be further desirable to be able to achieve this objective without the risk of data overruns, chaining checks or peripheral device controller signalled errors which occur as a result of requests for data or data transfers being in flight on an extended link.